home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Diamond Collection / The Diamond Collection (Software Vault)(Digital Impact).ISO / cdr48 / 386p_200.zip / 386VIDEO.TXT < prev    next >
Text File  |  1994-11-06  |  6KB  |  139 lines
  1. Some notes about 386video....
  2.  
  3. IT'S LIMITED
  4. The current 386video module does not exploit the full power
  5. of XVD drivers.
  6. I coded 386video with a generic interface (the interface won't change
  7. in the future releases), but with the underlying code focused for
  8. 320x200 256 colors screen modes only.
  9. If you want to exploit the full power of XVD drivers you'll have to
  10. enhance 386video yourself (sorry i'm too much under pressure to do it now).
  11.  
  12. RAM BUFFERING and the VRAM BOTTLENECK
  13.  
  14. I use RAM BUFFERING to render each frame, first i compose the next graphic
  15. image into SYSTEM RAM and then blit it to DISPLAY RAM.
  16. The main reason to use RAM BUFFERING  is that display ram is usually SLOWER
  17. than system ram, and usually display ram has lower i/o badwidth available
  18. to the processor.
  19. What's more, it is faster to cache system ram than display ram
  20. (again the i/o bottleneck).
  21. So if you have to access multiple times the display frame you are composing...
  22. ... it is better to render it on faster system ram and then copy it once
  23. to vram.
  24. Another reason to use ram buffering is that if you have only one visible
  25. display page you can't use the double display page trick, and when you
  26. update the display you have to be the fastest you can be.
  27. If you have only to copy the buffered image you are sure to use the fastest
  28. update method.
  29.  
  30. On some systems, a big cache and a good bus interface makes vram
  31. look as fast as system ram, but your program has to run even on
  32. "weak" systems with vram bandwidth bottlenecks.
  33.  
  34. DELTA BLITTING:
  35.  
  36. Plain ram buffering works well if system ram is a lot faster than vram
  37. AND you don't have bus bandwidth bottlenecks.
  38. Plain ISA bus has a 16bit width (8bit for some cards)
  39. and a standard 8Mhz clock, this translates to a 1..2 Mbyte/sec bandwidth
  40. when copying from memory to memory, while a plain 386/25 has at least a
  41. 4..8 Mbyte/sec available bandwidth when accessing system ram.
  42. Some systems support some "speeded up ISA" bus (mine can run ISA at
  43. 12Mhz, others support internal buffering and "fast cycling") but 
  44. even if you run on a 120 MIPS Pentium, with an ISA (8bit or 16bit) card
  45. you can't go far.
  46.  
  47. The answer to these bottlenecks is DELTA BLITTING, instead of
  48. blitting all the display page, blit only the differences between
  49. the previous display frame and the next.
  50.  
  51. Usually there are strong correlations between the image already displayed
  52. and the next still into system ram, so it is possible to boost
  53. animation speed a lot.
  54.  
  55. The speed of my 'test program'  was 23..24 Frames Per Second (FPS)
  56. with "simple ram buffering" while it skyrocketed to 56..60 FPS
  57. when turning on delta blitting.
  58.  
  59. Of course your mileage may vary, it depends on the programmer to 
  60. set up the appropriate "delta clipping" methods depending on what kind
  61. of animation you perform.
  62.  
  63. Maybe you are thinking "HA! Now there are VL-BUS and PCI
  64. i don't need to program for fucking old ISA ...".
  65. Well, given the current trend, the VL-BUS and PCI buses you think are fast now
  66. are gonna be a bottleneck to a 300Mhz SSPHARK
  67. (SuperScalar Processor from Hell with Advanced Risky Killpower ;) )
  68. driving a 4096x4096 24bit color mode on a 100 inches display.
  69.  
  70. HE TOUCHMAP
  71.  
  72. The bitmap you render on system ram contains the image you want on screen,
  73. if you want to "blit only the differences" you have to store
  74. some information to "remember" from a frame to another what's changed.
  75. I call this structure a TOUCHMAP, every time you modify (touch) the bitmap
  76. store some info on the touchmap, so when you will have to delta-blit
  77. you will use the touchmap to see where are the altered pixels to blit .
  78.  
  79. If you want speed, the "touchmap composition" has to be an algorithm
  80. of O(n) computational complexity  (linear) and the overhead has to be
  81. the least possible.
  82.  
  83. I evaluated various touchmapping methods, here comes the one i choosed:
  84.  
  85.         A bit-equivalent mask of the display bitmap where
  86.         ONE BIT in the TOUCHMAP
  87.         "marks" FOUR PIXELS (A DWORD) on the BITMAP.
  88.  
  89. The bitmap/touchmap size ratio is around 32/1 (quite good)
  90. and the touchbits are packed into DWORDS  (so, when you "touch", you use
  91. the massive speed of 32bit transferts, instead of slow bit-by-bit things).
  92. Using loop unrolling you can pump data to the video card at full speed.
  93.  
  94. Nota bene:
  95.  
  96. The touchmap is an ARRAY OF DWORDS, each bit into a dword is a flag
  97. for four consecutive pixels.
  98. The touchmap has as many rows as the logical display screen height in pixels
  99. and as many BITS as logical_display_screen_width/4 in pixels
  100. rounded up to a 32 multiple (so the lenght of a touchmap row can be
  101. expressed in dwords).
  102. When you manipulate the touchmap ALWAYS USE DWORD ACCESS, this is
  103. an absolute need to minimize "touchmap updating" overhead.
  104. I've tested various methods, the "dword sized" touchmap is faster
  105. than anything else on a 386 class processor animating lots of independent
  106. objects.
  107. This is due to the 32 to 1 ratio between actual pixel data and touchmap data
  108. and to the "always aligned dword" access you can use with this method.
  109. To further reduce memory usage i use a self-compiling "loop unroller"
  110. this way, instead of checking each bit i check a byte and call
  111. the appropriate "unrolled loop" for it.
  112. With this method i perform only one compare and call
  113. instead of eight compare and branch (this keeps my 386 happy
  114. because the less the jumps the more the pipeline stays filled and running)
  115.  
  116. WHY 256 COLORS ONLY
  117.  
  118. The 8bit/pixel  modes are the less processor intensive you can find
  119. (this means lots of speed), 256 colors are good enough for most games.
  120. You can blit 4 dots in a single memory access, mask quickly
  121. and implement fast compression/decompression methods if needed.
  122. If you think 16 or 24 bit/pixel modes are nicer to look at, you are right
  123. but the most common display cards use dynamic ram and this means the
  124. higher the video refresh bandwidth and the lower the cpu/blitter bandwidth.
  125. What's more, i want things capable to run in 4Mbyte, having bitmaps
  126. with two to four times the size of plain 256 color ones is no good.
  127.  
  128.  
  129.  
  130.  
  131. For further info and explanations look into 
  132. 386video.asm, 386video.inc, driver.txt, xvd.txt, makefile
  133. and the XVD driver sources (for example chips450.asm)
  134.  
  135. Ciao,
  136.    Lorenzo Micheletto   knight@maya.dei.unipd.it
  137.                         
  138.    
  139.